Tiding up conflicting logic on email alerts (Issue #943) #1249
Conversation
HTML2Text was being called on message, but we're sending messages as HTML. This was producing nasty emails and sad alertees. Removed the call to HTML2Text and wrapped functino on text::auto_p() to produce better looking messages
|
The original behaviour here was to send plain text emails.. I was working on the same issue for a client build recently but haven't had a chance to clean up my fix yet. Any thought on whether plain text or html message will work better? |
|
I reckon we have more general control of how it renders with HTML markup as I've seen line breaks go completely bust in plain text message in a few cases before. (This is a very weak argument though...) I'm not sure if SwiftMailer creates a text based version of the message as it sends it. I'll have a look and get back to you. |
|
I mean, I've seen a few email clients completely bust line breaks in plain text messages before. :) |
|
SwiftMailer doesn't automagically generate a text version of the message. Having said that, the text version for this particular case is not that unreadable. Another possible solution would be to update
This won't change current behaviour for anyone I think. :) |
|
Ooh. Sending an HTML and plain text version would definitely be good. It'd allow us to improve some of the existing message formatting too. One thing to watch for is that there are a few of the message templates that assume they'll be sent in plain text, so you might need to use |
|
I'll have a go at it. HTML2Text seems to be doing a very bad job on what it promisses - stripping line breaks and such. |
|
Update behaviour so:
HTML2Text is nice, the way the alerts function was mixing it up with the html header is not. I reckon this might call for a review of all calls to Wadjuracoon? |
| @@ -113,16 +113,22 @@ public static function connect($config = NULL) | |||
| * @param boolean send email as HTML | |||
| * @return integer number of emails sent | |||
| */ | |||
| public static function send($to, $from, $subject, $message, $html = FALSE) | |||
There was a problem hiding this comment.
I think you should be able to override/extend this function by adding a file application/helpers/MY_email.php. If we do it that way its easier to see whats been customised or not.
|
Definitely like this idea. You're right that we'll need to review all the other calls to email::send() since some of them do something similar to alerts. |
|
|
||
| // EMAIL MESSAGE | ||
| $email_message = $incident_description."\n\n".$incident_url; | ||
| $email_message = $incident_description . "\n\n" . $incident_url; | ||
|
|
||
| // SMS MESSAGE | ||
| $sms_message = $incident_description; |
There was a problem hiding this comment.
Need to update this to make sure we still remove HTML from the SMS message :)
|
reviewed the calls to email::send() and they are on $html = FALSE. |
Tiding up conflicting logic on email alerts (Issue #943)
HTML2Text was being called on message, but we're sending messages as HTML. This was producing nasty emails and sad alertees.
Removed the call to HTML2Text and wrapped function on text::auto_p() to produce better looking messages.